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Abstract 


TABLOG  (Tableau  Logic  Programming  Language)  is  a  language  based  on  first-order  pred¬ 
icate  logic  with  equality  that  combines  functional  and  logic  programming.  TABLOG  incor¬ 
porates  advantages  of  LISP  and  PROLOG. 

A  program  in  TABLOG  is  a  list  of  formulas  in  a  first-order  logic  (including  equality, 
negation,  and  equivalence)  that  is  more  general  and  more  expressive  than  PROLOG’S  Horn 
clauses.  Whereas  PROLOG  programs  must  be  relational,  TABLOG  programs  may  define 
either  relations  or  functions.  While  LISP  programs  yield  results  of  a  computation  by 
returning  a  single  output  value,  TABLOG  programs  can  be  relations  and  can  produce  several 
results  simultaneously  through  their  arguments. 

TABLOG  employs  the  Manna- Waldinger  deductive-tableau  proof  system  as  an  interpreter 
in  the  same  way  that  PROLOG  uses  a  resolution- based  proof  system.  Unification  is  used 
by  TABLOG  to  match  a  call  with  a  line  in  the  program  and  to  bind  arguments.  The  basic 
rules  of  deduction  used  for  computing  are  nonclausal  resolution  and  rewriting  by  means  of 
equality  and  equivalence. 

A  pilot  interpreter  for  the  language  has  been  implemented. 
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1.  Introduction 

Logic  programming  [Kowalski’ 79]  attempts  to  improve  programmer  productivity  by  propos¬ 
ing  logic,  a  human-oriented  language,  as  a  programming  language.  PROLOG,  the  flagship  of 
logic-programming  languages,  based  on  a  resolution  proof  system,  has  a  restricted  syntax. 
TABLOG  is  based  on  a  more  flexible  theorem  prover,  the  deductive-tableau  proof  system 
[Manna  and  Waldinger  80],  which  allows  a  more  intuitive  and  a  richer  syntax.  A  TABLOG 
program  is  a  list  of  assertions  in  [quantifier-free]  first-order  logic  with  equality.  The  execu¬ 
tion  of  a  program  corresponds  to  the  proof  of  a  goal,  which  produces  the  desired  output  (s) 
as  a  side  effect. 

Since  a  particular  procedure  is  specified  by  the  programmer,  and  since  the  proof  taking 
place  is  always  a  proof  of  a  special  case  of  a  theorem — namely,  the  case  for  the  given  input — 
the  program  interpreter  does  not  need  all  the  deduction  rules  available  in  the  original 
deductive-tableau  proof  system.  The  theorem  prover  can  be  more  directed,  efficient,  and 
predictable  than  a  theorem  prover  used  for  program  synthesis  or  for  any  other  general- 
purpose  deduction. 

2.  TABLOG  Syntax 

Syntactic  Objects 

The  language  is  that  of  the  quantifier-free  first-order  predicate  logic  with  equality,  consist¬ 
ing  of  the  following: 

•  truth  values:  true,  false. 

•  connectives:  A,  V,  =,  — *■  {implies),  *—  {if),  if-then-else. 

•  variables  such  as  u,  v ,  X\ ,  y25- 

•  constants  such  as  a,  b,  [],  5. 

•  predicates  such  as  =,  prime,  €,  >. 

•  functions  such,  as  gcd,  append,  +. 

The  user  must  declare  the  variables,  constants,  functions,  and  predicates  used  in  the 
program;  some  primitive  constants,  functions,  and  predicates  (such  as  0,  [],  + ,  — ,  >,  odd) 
are  predefined. 

Note  that  we  use  the  if-then-else  construct,  both  as  a  connective  for  formulas 

if  u  —  |  ]  then  empty  (u)  else  sorted(u) 

and  as  an  operator  generating  terms 

gcd(z,  y)  =  if  x  >  y  then  gcd {x~y,  y) 

else  gcd(x,  y~x). 

This,  together  with  +—  (reverse  implication),  enables  the  programmer  to  write  LISP-style 
as  well  as  PROLOG-style  programs. 
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Programs 

A  program  is  a  list  of  assertions  (formulas  in  [quantifier- free]  .first-order  logic  with  equality), 
specifying  the  algorithm.  Variables  are  implicitly  universally  quantified. 

Here  is  a  very  simple  program  for  appending  two  lists: 

append([],u)  =  v 

append(iou,  v)  =  zoappend(u,  v). 

The  o  symbol  denotes  the  list  insertion  (cons  in  LISP)  operator,  and  []  denotes  the  empty 
list  (nil  in  LISP). 

A  call  to  a  program  is  a  goal  to  be  proved.  Like  the  assertions,  goals  are  formulas 
in  logic,  but  variables  are  implicitly  existentially  quantified.  The  bindings  of  these  vari¬ 
ables  are  recorded  throughout  the  proof  and  become  the  outputs  of  the  program  upon 
termination. 

For  example,  a  call  to  the  append  program  above  might  be 

2  =  append([l, 2, 3],  [a,b]). 

The  output  of  the  execution  of  this  program  call  will  be 

[1, 2, 3,  a,  £>], 


as  expected. 

The  list  construct  (e.g.  [1,2, 3])  is  for  convenience  in  expressing  input  and  output,  and 
denotes  the  term  lo(2o(3o| '])). 

3.  Examples 

The  following  examples  demonstrate  the  basic  features  of  TABLOG.  The  correctness  of 
these  programs  does  not  depend  on  the  order  of  assertions  in  the  program.  It  is  possible, 
however,  to  write  programs  that  do  take  advantage  of  the  known  order  of  the  interpreter’s 
goal  evaluation,  els  will  be  explained  later.  ' 

In  the  examples,  we  use  x  and  y  (possibly  with  subscripts)  for  variables  intended  to  be 
assigned  atoms  (integers  in  most  of  the  examples);  u  and  v  (possibly  with  subscripts)  are 
variables  used  for  lists. 

Deleting  a  List  Element 

The  following  program  deletes  all  [top-level]  occurrences  of  an  element  x  from  a  list: 
deleted,  [])  =  [] 

delete(x,  you )  =  (if  x  =  y  then  delete  (:e,  a) 

else  y  o  delete(z,  u)) . 
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This  program  demonstrates  the  use  of  equality,  if-then-else,  and  recursive  calls.  For  those 
who  prefer  the  PROLOG  style  of  programming,  the  last  line  could  be  replaced  by  assertions: 

delete(x,  xou)  =  delete(x, u) 
x  7 —*  delete(x,  you)  =  yodelete(x,u) 

To  remove  all  occurrences  of  a  from  the  list  [a,  b,  a,  c]  the  goal 

z  =  delete(a,  [a,  b,  a,  cj) 


is  given  to  the  interpreter. 

Set  Union 

The  following  example,  a  program  to  find  the  union  of  two  sets  represented  by  lists,  demon¬ 
strates  the  use  of  negation,  equivalence  and  if-then-else : 

1.  union([],  v)  =  v 

2.  union(xou,  v)  —  if  member (x,  v) 

then  union(u,  v) 
else  (xounion(u,  v)) 

3.  ->member(x,  []) 

4.  member(i,  you )  =  ((x  =  y)  V  member(x,  u)) 

Lines  1  and  2  define  the  union  function.  Line  1  defines  the  union  of  the  empty  set 
with  another  set,  and  line  2  asserts  that  the  head  x  of  the  first  set  xou  should  be  inserted 
into  the  union  if  it  is  not  already  in  the  second  set  v. 

Lines  3  and  4  define  the  member  relation.  Line  3  specifies  that  no  element  is  a  member 
of  the  empty  set,  and  line  4  defines  how  to  test  recursively  membership  in  a  nonempty 
set. 

Factorial 

The  following  program  will  compute  the  factorial  of  a  nonnegative  integer  x: 
fact(O)  =  1 

fact(x)  =  x  *  fact(x  —  1)  <—  x  >  1 

The  corresponding  PROLOG  program  will  be 
factp(0, 1) 

factp(x,x)  xi  isx-1  A  factp(xj,t/)  A  z  is  x  *  y. 

The  is  construct  is  used  in  PROLOG  to  force  the  evaluation  of  an  arithmetic  expression. 
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Quicksort 

Here  is  a  TABLOG  program  that  uses  quicksort  to  sort  a  list  of  numbers.  It  combines  a 
PROLOG-style  relational  subprogram  for  partitioning  with  a  LISP-style  functional  subpro¬ 
gram  for  sorting. 

1.  qsort([])  =  [] 

2.  qsort(xotx)  =  append(qsort(ixi ),  zoqsort^)) 

<—  partition(x,ix,ixi,ix2) 

3.  partition^,  [],[],[]) 

4.  partition(x,  you,  you\ ,  ui) 

*—  y  <  x  A  partition(x,  ix, ui,u.2) 

5.  partition(x,  you,  u\ ,  you2) 

*—  y  >  x  A  partition(x,  ix,txi,ix2) 

The  assertions  in  lines  1  and  2  form  the  sorting  subprogram.  Line  1  asserts  that  the 
empty  list  is  already  sorted.  Line  2  specifies  that,  to  sort  a  list  xo u,  with  head  x  and  tail 
u,  one  should  append  the  sorted  version  of  two  sublists  of  ix,  tzi  and  1*2 ,  and  insert  the 
element  x  between  them;  the  two  sublists  1x1  and  142  are  determined  by  the  subprogram 
partition  to  be  the  elements  of  u  less  than  or  equal  to  x  and  greater  than  x,  respectively. 

The  assertions  in  lines  3  to  5  specify  how  to  partition  a  list  according  to  a  partition 
element  x.  Line  3  discusses  the  partitioning  of  the  empty  list,  while  lines  4  and  5  treat  the 
case  in  which  the  list  is  of  the  form  you.  Line  4  is  for  the  case  in  which  y.  the  head  of  the 
list,  is  less  than  or  equal  to  x;  therefore,  y  should  be  inserted  into  the  list  1x1  of  elements 
not  greater  than  x.  Line  5  is  for  the  alternative  case. 

The  append  function  for  appending  two  lists  was  defined  earlier. 

4.  Comparison  with  PROLOG 

Functions  and  Equality 

While  PROLOG  programs  must  be  relations,  TABLOG  programs  can  be  either  relations  or 
functions.  The  availability  of  functions  and  equality  makes  it  possible  to  write  programs 
more  naturally.  The  functional  style  of  programs  frees  the  programmer  from  the  need  to 
introduce  many  auxiliary  variables. 

We  can  compare  the  PROLOG  and  TABLOG  programs  for  quicksort.  In  TABLOG,  the 
program  uses  the  unary  function  qsort  to  produce  a  value,  whereas  a  PROLOG  program  is 
a  binary  relation  qsortp;  the  second  argument  is  needed  to  hold  the  output. 

The  second  assertion  in  the  TABLOG  program  is 

qsort(xoxx)  =  append(qsort(ui),xoqsort(iX2)) 

<—  partition(x,  ix,  1x1, 1x2) 
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The  corresponding  clause  in  the  PROLOG  program  will  be  something  like 

qsortp(zou,  z)  <—  partition^,  u,  U\ ,  u2)  A 
qsortp('Ui ,  z\)  A 
qsortp(u2,^2)  A 
appendp(2i  ,10  Z2,z). 

The  additional  variables  z\  and  Z2  are  required  to  store  the  results  of  sorting  ui  and  ui  • 
This  demonstrates  the  advantage  of  having  functions  and  equality  in  the  language.  Note 
that,  although  function  symbols  exist  in  PROLOG,  they  are  used  only  for  constructing  data 
structures  (like  TABLOG’s  primitive  functions)  and  are  not  reduced. 

Negation  and  Equivalence 

In  PROLOG,  negation  is  not  available  directly;  it  is  simulated  by  finite  failure.  To  prove 
not(P ),  PROLOG  attempts  to  prove  P\  not(P)  succeeds  if  and  only  if  the  proof  of  P  fails. 
In  TABLOG,  negation  is  treated  like  any  other  connective  of  logic.  Therefore,  we  can  prove 
formulas  such  as  ->member(l,  [2, 3]). 

The  TABLOG  union  program,  described  earlier,  uses  both  equivalence  and  negation: 
union([],u)  =  v 

union(xou,  u)  =  if  member(i,n) 

then  union(u,u) 
else  (zounion(u,  v)) 

->member(x,  []) 

member (x,  you)  =  (x  =  y)  V  member(z,  u). 

Here  is  a  possible  PROLOG  implementation  of  the  same  algorithm: 

unionp(zou,  v,  z)  «—  memberp(z,u)  A  unionp(u,  v,z) 
unionp(zou,  v,  xoz)  +—  unionp(u,  v,  z) 
unionp([],u,  v) 

memberp(x,  xou) 

memberp(z, you)  <—  memberp(i,u). 

Changing  the  order  of  the  first  two  clauses  in  the  PROLOG  program  will  result  in  an 
incorrect  output;  the  second  clause  is  correct  only  for  the  case  in  which  x  is  not  a  member 
of  v.  The  TABLOG  assertions  can  be  freely  rearranged;  this  suggests  that  all  of  them  can 
be  matched  against  the  current  goal  in  parallel,  if  desired. 

Unification 

The  unification  procedure  built  into  PROLOG  is  not  really  unification  (e.g.,  as  defined 
in  [Robinson  65]);  it  does  not  fail  in  matching  an  expression  against  one  of  its  proper 
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subexpressions  since  it  lacks  an  occur-check.  When  a  theorem  prover  is  used  as  a  program 
interpreter,  the  omission  of  the  occur-check  makes  it  possible  to  generate  cyclic  expressions 
that  may  not  correspond  to  any  concrete  objects. 

The  unification  used  by  the  TABLOG  interpreter  does  include  an  occur-check,  so  that 
only  theorems  can  indeed  be  proved. 

5.  Comparison  with  LISP 

LISP  programs  are  functions,  each  returning  one  value;  the  arguments  of  a  function  must 
be  bound  before  the  function  is  called.  In  TABLOG,  on  the  other  hand,  programs  can  be 
either  relations  or  functions,  and  the  arguments  need  not  be  bound;  these  arguments  will 
later  be  bound  by  unification. 

We  can  illustrate  this  with  the  quicksort  program  again,  concentrating  on  the  partition 
subprogram.  In  TABLOG,  we  have  seen  how  to  achieve  the  partition  by  a  predicate  with 
four  arguments,  two  for  input  and  two  for  output: 

1.  partition^,  [],[],[]) 

2.  partition(x, you,i/otii,U2) 

*—  y  <  x  /\  partition(x,u,  ui ,  U2) 

3.  partition(x,you, u\,y 0U2) 

*—  y  >  x  A  partition(x, u, tti,U2) 

The  definition  of  the  program  partition  is  much  shorter  and  cleaner  them  the  corre¬ 
sponding  LISP  program: 

highpart(x,  u)  •<= 

if  null(u)  then  nil 

else-if  x  >  car(u)  then  highpart(x,  cdr(u)) 
else  cons(car(u),highpart(x,  cdr(u))) 

lowpart(x,  u)  <= 

if  null(u)  then  nil 
else-if  x  >  car(u) 

then  cons(car(u),  lowpart(x,  cdr(u))) 
else  lowpart(x,  cdr(u)). 

We  can  generate  the  two  sublists  in  LISP  simultaneously,  but  this  will  require  even  more 
pairing  and  decomposition. 

Note  that  unification  also  gives  us  “free”  decomposition  of  the  list  argument  into  its 
head  and  tail;  in  the  LISP  program,  this  decomposition  requires  explicit  calls  to  the  func¬ 
tions  car  and  cdr. 
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6.  The  Deductive- Tableau  Proof  System 

In  this  section,  we  give  a  brief  summary  of  the  Manna- Waldinger  deductive-tableau  proof 
system  [Manna  and  Waldinger  80  and  82].  This  proof  system  is  used  as  the  TABLOG 
interpreter.  We  describe  only  the  deduction  rules  actually  employed  in  it. 

A  deductive  tableau  consists  of  rows,  each  containing  either  an  assertion  or  a  goal.  The 
assertions  and  goals  (both  of  which  we  refer  to  by  the  generic  name  entries)  are  first-order 
logic  formulas;  the  theorem  is  proved  by  manipulating  them.  The  declarative  or  logical 
meaning  of  a  tableau  is  that,  if  every  instance  of  all  the  assertions  is  true,  then  some 
instance  of  at  least  one  of  the  goals  is  true.  The  assertions  in  the  tableau  are  like  clauses 
in  a  standard  resolution  theorem  prover — but  they  can  be  arbitrary  first-order  formulas, 
not  just  disjunctions  of  literals. 

The  theorem  to  be  proved  is  entered  as  the  initial  goal.  A  proof  is  constructed  by  adding 
new  goals  to  the  tableau,  using  deduction  rules,  in  such  a  way  that  the  final  tableau  is 
semantically  equivalent  to  the  original  one.  The  proof  is  complete  when  we  have  generated 
the  goal  true. 

Deduction  Rules 

The  basic  rules  used  for  the  program  execution  task  are  the  following: 

•  Nonclausal  Resolution:  This  generalized  resolution  rule  allows  removal  of  a  subfor¬ 

mula  P  from  a  goal  Q[P)  by  means  of  an  appropriate  assertion  A[P].  Resolving 
the  goal 

m 

with  the  assertion 

provided  that  P  and  P  are  unifiable,  i.e.,  P9  =  P9  for  some  (most-general)  unifier 
9,  we  get  the  new  goal 

not(A'[false])  A  p'[frue], 

where  A' [false]  is  A9  after  all  occurrences  of  P9  have  been  replaced  by  false ,  and 
similarly  for  Q'[true).  This  deduction  rule  can  be  justified  by  case  analysis. 

The  choice  of  the  unified  subformulas  is  governed  by  the  polarity  strategy  [Murray 
82].  A  subformula  has  positive  polarity  if  it  occurs  within  an  even  number  of 
(explicit  or  implicit)  negations,  and  has  negative  polarity  if  it  occurs  within  an 
odd  number  of  negations.  (An  assertion  has  an  implicit  negation  applied  to  it.)  A 
subformula  can  occur  both  positively  and  negatively  in  a  formula.  According  to 
the  polarity  strategy,  the  subformula  P  will  be  replaced  by  false  only  if  it  occurs 
with  negative  polarity  and  the  subformula  Q  will  be  replaced  by  true  only  if  it 
occurs  with  positive  polarity. 

•  Equality  Rule:  An  asserted  [possibly  conditional]  equality  of  two  terms  can  be  used 

to  replace  one  of  the  terms  with  the  other  in  a  goal.  If  the  asserted  equality  is 
conditional,  the  conditions  are  added  to  the  resulting  goal  as  conjuncts. 
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Thus,  suppose  the  assertion  is  of  the  form 

A[s  =  *]. 

and  the  goal  is 

£[«]■ 

where  s  and  s  are  unifiable,  i.e.,  s8  =  s6  for  some  unifier  8.  Then  we  get  the  new 
goal 

not(A' [false])  A 

where  A'[false]  is  A8  after  all  occurrences  of  the  equality  s8  =  t8  (which  should 
occur  with  negative  polarity)  have  been  replaced  by  false,  and  where  C(\l!)  is  Q8 
after  the  replacement  of  all  occurrences  of  the  term  s8  by  td. 

The  reflexivity  axiom  for  equality  x  =  x  is  implicitly  included  among  the  asser¬ 
tions  of  every  tableau. 

•  Equivalence  Rule:  The  replacement  of  one  subformula  by  another  asserted  to  be 

equivalent  to  it.  This  is  completely  analogous  to  the  equality  rule  except  that  we 
replace  atomic  formulas  rather  than  terms,  using  equivalence  rather  then  equality. 

•  Simplification :  The  replacement  of  a  formula  by  an  equivalent  but  simpler  formula. 

Both  propositional  and  arithmetic  simplification  are  performed  automatically  by 
the  TABLOG  interpreter. 

While  nonclausal  resolution  and  the  equivalence  rule  can  be  performed  unifying  arbi¬ 
trary  subformulas,  the  TABLOG  interpreter  applies  these  deduction  rules  unifying  atomic 
subformulas  only. 

7.  Program  Semantics 

The  logical  interpretation  of  a  tableau  containing  a  TABLOG  program  and  a  call  to  it  is 
the  logical  sentence  associated  with  the  tableau:  the  conjunction  of  the  universal  closures 
of  the  assertions  implies  the  existential  closure  of  the  goal. 

The  desired  goal  is  reduced  to  true  by  means  of  the  assertions  and  the  deduction  rules. 
The  variables  are  bound  when  subexpressions  of  the  goal  (or  derived  subgoals)  are  unified 
with  subexpressions  of  the  assertions.  The  order  of  the  reduction  is  explained  in  the  next 
section.  The  output  of  the  program  is  the  final  binding  of  the  variables  of  the  original  goal. 

We  distinguish  between  defined  functions,  whose  semantics  is  defined  by  the  user  pro¬ 
gram,  and  primitive  functions,  which  are  either  data  constructors  (e.g.,  o),  or  are  built-in 
and  have  their  semantics  defined  by  attached  procedures  in  the  simplifier;  for  example,  an 
expression  like  (2  +  x  +  5)  o  []  is  considered  primitive  and  will  be  automatically  simplified 
to  (x  +  7) o []. 

As  in  PROLOG,  variables  are  local  to  the  assertion  or  goal  in  which  they  appear.  Re¬ 
naming  of  variables  is  done  automatically  by  the  interpreter  when  there  is  a  collision  of 
names  between  the  goal  and  assertion  involved  in  a  derivation  step. 

The  variables  of  the  original  goal  are  the  output  variables.  The  interpreter  keeps  their 
binding  throughout  the  derivation;  the  same  variable  name  can  be  used  for  a  different 
purpose  in  other  assertions  or  goals. 
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8.  Program  Execution 

Every  line  in  a  program  is  an  assertion  in  the  tableau;  a  call  to  the  program  is  a  goal  in 
the  same  tableau. 

The  tableau  system  provides  us  with  deduction  rules  but  with  no  specific  order  in 
which  to  apply  them.  To  use  it  as  a  programing  language,  we  have  to  specify  the  order  of 
application  both  for  predictability  and  for  efficiency. 

The  proof  system  is  used  to  execute  programs  in  a  way  analogous  to  the  inversion 
of  a  matrix  by  linear  operations  on  its  rows,  where  we  simultaneously  apply  the  same 
transformations  to  the  matrix  to  be  inverted  and  to  the  identity  matrix.  In  the  program 
execution  process,  we  start  with  a  tableau  containing  the  assertions  of  the  program  and  a 
goal  calling  this  program;  we  apply  the  same  substitutions  (obtained  by  unification)  to  the 
current  subgoal  and  to  the  binding  of  the  output  variables.  A  matrix  inversion  is  complete 
when  we  reduce  the  original  matrix  to  the  identity  matrix;  in  TABLOG  we  are  done  when 
we  have  reduced  the  original  goal  to  true.  At  this  point,  the  result  of  the  computation  is 
the  final  binding  of  the  output  variables. 

Although  in  the  declarative  (logical)  semantics  of  the  tableau  the  order  of  entries  is 
immaterial,  the  procedural  interpretation  of  the  tableau  as  a  program  takes  this  order  into 
account;  changing  the  order  of  two  assertions  or  changing  the  order  of  the  conjuncts  or 
disjuncts  in  an  assertion  or  a  goal  may  produce  different  computations. 

The  user  for  his  part,  has  to  specify  an  algorithm  by  employing  the  predefined  order  of 
evaluation  of  the  tableau.  At  each  step  of  the  execution,  one  basic  expression  (a  nonvariable 
term  or  an  atomic  formula)  of  the  current  goal  is  reduced.  The  expression  to  be  reduced  is 
selected  by  scanning  the  goal  from  left  to  right.  The  first  (leftmost)  basic  expression  that 
has  only  primitive  arguments  (i.e.,  that  contain  only  variables,  constants,  and  primitive 
functions)  is  chosen  and  reduced,  if  possible.  Matching  the  selected  expression  against 
assertions  is  done  in  order  of  appearance. 

This  is  best  explained  with  an  example: 

To  sort  the  list  [2, 1,4, 3]  using  quicksort,  we  write  the  goal 

z  =  qsort([2, 1, 4, 3]). 

To  execute  this  goal,  the  expression  chosen  for  reduction  will  be  the  term  qsort([2, 1,4, 3]), 
i.e.,  qsort(2o[l,4, 3]).  This  term  unifies  with  the  leftmost  term  qsort(xou)  in  the  second 
assertion  of  the  quicksort  program, 

qsort(xou)  =  append(qsort(ui  ),xoqsort(u2)) 

<—  partition(x,u,tii,U2). 

According  to  the  equality  rule,  it  will  be  replaced  by  the  corresponding  instance  of  the 
right-hand  side  of  the  equality;  this  is  done  only  after  the  unifier 

{x  2,  u-  [1,4,3]} 
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is  applied  to  both  the  goal  and  the  assertion.  The  occurrence  of  the  equality 
qsort(2o[l,4, 3])  =  append  (qsort  (tt] ),  2oqsort(u2)) 
is  replaced  by  false  in  the  [modified]  assertion,  the  occurrence  of  the  term 

qsort(2o  [1,4,3]) 


is  replaced  by  the  term 

append  (qsort  (ui ) ,  2  o  qsort  (u2 ) ) 
in  the  (modified)  goal,  and  a  conjunction  is  formed,  obtaining 

not(false  «—  partition(2,[l,4,3],ui,U2)  A 
z  —  append(qsort{ui),  2oqsort(tt2)). 

This  formula  can  be  reduced  by  the  simplifications 

(false  <—  P)  =>  not  P 

and 

not(not  P)  =>  P 

to  obtain  the  new  goal 

partition(2,  [1,4, 3],  ui ,  U2)  A 
z  =  append{qsort{tii ),  2oqgort{ti2))- 

Continuing  with  this  example,  we  now  have  a  case  in  which  the  expression  to  be  reduced 
is  an  atomic  formula,  namely, 


partition(2,  [1, 4, 3],  u\ ,  a?). 

This  atomic  formula  is  unifiable  with  a  subformula  in  the  second  assertion  of  the  partition 
subprogram  (with  variables  renamed  to  resolve  collisions) 

partition(a:,  you,  you3,  U4) 

<—  y  <  x  A  partition(a;,u,'U3,u4). 

Nonclausal  resolution  is  now  performed  to  further  reduce  the  current  goal.  The  unifier 
{z  «-  2,  y  <—  1,  u  <—  [4,3],  ui  I0U3,  u2  *-u4} 
is  applied  to  both  the  assertion  and  the  goal;  the  formula 

partition(2,  [1,4,3],  lou3,u4) 
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is  replaced  by  false  in  the  [modified]  assertion  and  by  true  in  the  goal.  Once  again  a 
conjunction  is  formed  and  the  new  goal  generated  (after  simplification)  is 

partition(2,  [4, 3],U3,rz4)  A 
z  =  append(qsort(lou3),  2oqsort(u4)}. 

Eventually  we  reach  the  snbgoal 

*  =  M,3,4I, 

where  the  right-hand  side  of  the  equality  contains  only  primitive  functions  and  constants. 
The  execution  then  terminates  and  the  desired  output  is 

[1,2,3, 4]. 

Note  that  some  functions  and  predicates  (e.g.,  o  in  this  example)  are  predefined  to  be 
primitive;  an  expression  in  which  such  a  symbol  is  the  main  operator  is  never  selected  to 
be  reduced,  although  its  subexpressions  may  be  reduced. 

Backtracking 

If  the  selected  expression  cannot  be  reduced,  the  search  for  other  possible  reductions  is 
done  by  backtracking. 

In  PROLOG  each  goal  is  a  conjunction,  so  all  the  conjuncts  must  be  proved;  this  means 
that,  when  facing  a  dead  end,  we  have  to  undo  the  most  recent  binding  and  try  other 
assertions. 

In  TABLOG  the  situation  is  more  complex:  each  goal  (and  each  assertion)  is  an  arbi¬ 
trary  formula,  so  it  is  possible  to  satisfy  it  without  satisfying  all  its  atomic  subformulas. 
Therefore,  when  the  TABLOG  interpreter  fails  to  find  an  assertion  that  reduces  some  basic 
expression,  it  tries  to  reduce  the  next  expression  that  can  allow  the  proof  to  proceed.  In 
the  case  in  which  the  expression  that  cannot  be  reduced  is  “essential”  (for  example,  a  con¬ 
junct  in  a  conjunctive  goal),  no  other  subexpression  will  be  attempted  and  backtracking 
will  occur. 

During  backtracking,  the  goal  from  which  the  current  goal  was  derived  becomes  the  new 
current  goal,  but  the  next  plausible  assertion  is  used.  This  is  similar  to  the  backtracking 
used  in  PROLOG. 

The  Implementation 

A  prototype  interpreter  for  TABLOG  is  implemented  in  MACLISP.  The  implemented  system 
serves  as  a  program  editor,  debugger,  and  interpreter.  All  the  examples  mentioned  in  this 
paper  have  been  executed  on  this  interpreter. 

The  backtracking  mechanism  provides  a  simple  way  of  changing  the  interpreter  so 
that  lazy  evaluation  can  be  employed — i.e.,  so  that  attempts  can  be  made  to  evaluate 
expressions  even  if  they  have  nonprimitive  arguments. 

Because  the  interpreter  is  built  on  top  of  a  versatile  theorem-proving  system,  the  exe¬ 
cution  of  programs  is  relatively  slow.  The  interpreter  now  handles  complicated  cases  that 
might  arise  in  a  more  general  theorem-proving  task,  but  will  never  occur  in  TABLOG.  We 
hope  that  performance  will  be  improved  considerably  by  tuning  the  simplifier  and  utilizing 
tricks  from  PROLOG  implementations  to  make  the  binding  of  variables  faster. 
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9.  Related  Research 


Logic  programming  has  become  a  fashionable  research  topic  in  recent  years.  Most  of  the 
research  relates  to  PROLOG  and  its  extensions.  We  mention  here  some  of  the  work  that 
has  been  done  independently  of  TABLOG  to  generate  languages  similar  to  TABLOG  in  their 
intention  and  capabilities. 

While  the  deductive-tableau  theorem  prover  used  for  TABLOG  execution  is  based  on 
a  generalized  resolution  inference  rule,  [Haridi  81],  [Haridi  and  Sahlin  83],  and  [Hansson, 
Haridi,  and  Tarnlund  82]  describe  a  programming  language  based  on  a  natural-deduction 
proof  system.  They  do  allow  quantifiers  and  other  connectives  in  the  language  but  the 
syntax  of  their  assertions  is  somewhat  restricted. 

[Komfeld  83]  extends  PROLOG  to  include  equality,  asserting  equality  between  two  ob¬ 
jects  in  his  language  causes  the  system  to  unify  these  objects  when  regular  unification  fails. 
This  makes  it  possible  to  unify  objects  that  differ  syntactically.  Kornfeld  treats  only  Horn 
clauses  and  does  not  introduce  any  substitution  rule  either  for  equality  or  for  equivalence. 

[Tamaki  84]  extends  PROLOG  by  introducing  a  reducibility  predicate,  denoted  by  >. 
This  predicate  has  semantics  similar  to  the  way  TABLOG  uses  equality  for  rewriting  terms. 
This  work  also  includes  f-symbols  and  d- symbols  that  are  analogous  to  TABLOG ’s  distinction 
between  defined  and  primitive  functions.  The  possible  nesting  of  terms  is  restricted  and 
programs  must  be  in  Horn  clause  form. 

OBJ  [Goguen,  Meseguer,  and  Plaisted  82]  is  also  related  to  logic  programming.  It  is 
based,  however,  on  the  algebraic  semantics  of  abstract  data  types  and  equational  theory 
rather  than  on  [resolution- based]  theorem  proving  in  first-order  logic.  OBJ  1  is  an  advanced 
implementation  of  the  language  that  allows  parameterized  and  hierarchical  programming. 
OBJ  1  includes  system  features  for  convenience  and  efficiency;  it  uses  one-way  pattern 
matching  to  apply  rewrite  rules  rather  than  two-way  unification.  [Goguen  and  Meseguer 
84]  describes  EQLOG,  the  extension  of  OBJ  to  include  unification  and  Horn  clauses. 

There  are  PROLOG  systems,  such  as  LOGLISP  [Robinson  and  Sibert  82]  and  QLOG 
[Komorowski  79  and  82]  that  are  implemented  within  LISP  systems.  These  systems  allow 
the  user  to  invoke  the  PROLOG  interpreter  from  within  a  LISP  program  and  vice  versa.  In 
TABLOG,  however,  LISP-like  features  and  PROLOG-like  features  coexist  peacefully  in  the 
same  framework  and  are  processed  by  the  same  deductive  engine. 

10.  Conclusions  and  Discussion 

The  TABLOG  language  is  a  new  approach  to  logic  programming:  instead  of  patching  up 
PROLOG  with  new  constructs  to  eliminate  its  shortcomings,  we  suggest  a  more  powerful 
deductive  engine. 

The  combination  in  TABLOG  of  unification  as  a  binding  mechanism,  equality  for  speci¬ 
fying  functions,  and  first-order  logic  for  specifying  predicates  creates  a  rich  language  that 
is  clean  from  a  logical  point  of  view.  As  a  consequence,  programs  correspond  to  our  intu¬ 
ition  and  are  easier  to  write,  read,  and  modify.  We  can  mix  LISP-style  and  PROLOG-style 
programming  and  use  whichever  is  more  convenient  for  the  problem  or  subproblem. 
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By  restricting  the  general-purpose  deductive-tableau  theorem  prover  and  forcing  it  to 
follow  a  specific  search  order,  we  have  made  it  suitable  to  serve  as  a  program  interpreter; 
the  specific  search  order  makes  it  both  more  predictable  and  more  efficient  than  attempting 
to  apply  the  deduction  rules  arbitrarily. 

While  the  theorem  prover  supports  reasoning  with  quantified  formulas  [Manna  and 
Waldinger  82;  Bronstein  83],  the  ramifications  of  including  quantifiers  in  the  language 
are  still  under  investigation.  Quantifiers  would  certainly  enhance  the  expressive  power 
of  TABLOG,  but  we  believe  that  they  are  more  suited  to  a  specification  language  than  a 
programming  language. 

It  seems  very  natural  to  extend  TABLOG  to  parallel  computation.  The  inclusion  of  real 
negation  makes  it  possible  to  write  programs  that  do  not  depend  on  the  order  of  assertions. 

The  extension  of  TABLOG  to  support  concurrent  programs  is  being  pursued.  If  the 
conditions  of  the  assertions  are  disjoint,  several  assertions  can  be  matched  against  the 
current  subgoal  in  parallel.  In  addition,  disjunctive  goals  can  be  split  between  processes. 
If  there  are  no  common  variables,  conjuncts  can  be  solved  in  parallel;  otherwise  some  form 
of  communication  is  required. 

The  or-parallelism  and  and-parallelism  suggested  for  PROLOG  are  applicable  for  TAB- 
LOG  as  well.  The  or-parallelism  of  PROLOG  relates  to  matching  against  many  assertions; 
in  TABLOG  or-parallelism  is  possible  within  every  goal,  since,  for  example,  goals  can  be 
disjunctive.  In  TABLOG  can  other  forms  of  parallelism  can  be  applied  to  nested  function 
calls. 
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